Remote management of application settings

ABSTRACT

In various implementations, a computer-implemented method for remotely managing settings of applications includes receiving a network communication from a managed device, the received network communication including a client-side hash value. The method further includes identifying settings for an application on the managed device in response to the receiving of the network communication, where the identified settings include configuration instructions for the application. Based on a comparison between the received client-side hash value and a server-side hash value that corresponds to the identified settings, at least some of the identified settings are transmitted to the managed device. The transmitting of at least some of the identified settings can be based on the comparison indicating a mismatch between the received client-side hash value and the server-side hash value. The method may also include completing processing of the received network communication after the transmitting of the at least some of the identified settings.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a Continuation of U.S. patent application Ser. No.16/775,700 filed Jan. 29, 2020, which is itself a Continuation of U.S.patent application Ser. No. 14/528,526 filed Oct. 30, 2014, and nowissued as U.S. Pat. No. 10,554,788, which itself claims the benefit ofU.S. Provisional Application No. 62/053,102, filed on Sep. 19, 2014, theentire contents of each of the foregoing applications being incorporatedby reference herein in their entirety.

BACKGROUND

Smartphones have driven the widespread adoption of applicationmarketplaces. Beyond smartphones, it has become increasingly common forapplication marketplaces to target other types of computing devices. Inthis respect, application marketplaces can commonly be found for othertypes of mobile devices, including tablet computers, laptops, andsmartwatches, as well as for desktop computers, and other computingdevices. Application marketplaces provide features for managingapplications that typically include discovering, downloading, andupdating the applications. However, the feature sets of applicationmarketplaces can be limited and typically do not extend beyond basicapplication distribution. Furthermore, the feature sets can vary betweenapplication marketplaces, which can introduce the risk of fragmenting adeveloper's user base, particularly in the cross-platform environment.As such, developers may seek other application management solutions toovercome any of the various limitations of application marketplaces.

SUMMARY

Embodiments of the present invention are directed to remote managementof application settings. Applications can be distributed to manageddevices utilizing an application marketplace or another distributionmeans. Upon an application being installed on a managed device, adeveloper may wish to modify, add, delete, replace, or otherwise manageone or more settings associated with the application. A remote settingsservice is described herein that enables remote management ofapplication settings. The remote settings service can facilitatereal-time, or near real-time, management of applications installed onmanaged devices. As a result, settings associated with an applicationinstalled on a managed device can be modified without having toreinstall the application or wait an extended period of time formodifications.

This summary is provided to introduce a selection of concepts in asimplified form that are further described below in the detaileddescription. This summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used in isolation as an aid in determining the scope of the claimedsubject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

Implementations of the present disclosure are described in detail belowwith reference to the attached drawing figures, wherein:

FIG. 1 illustrates an exemplary system which can be utilized forremotely managing settings of applications in accordance withimplementations of the present disclosure;

FIG. 2 illustrates an exemplary remote settings service in accordancewith implementations of the present disclosure;

FIG. 3 depicts an exemplary network communication in accordance withimplementations of the present disclosure;

FIG. 4 depicts a flow diagram of an exemplary method remotely managingsettings of applications in accordance with implementations of thepresent disclosure;

FIG. 5 depicts a flow diagram of an exemplary method remotely managingsettings of applications in accordance with implementations of thepresent disclosure; and

FIG. 6 is a diagram of an exemplary computing environment suitable foruse in implementations of the present disclosure;

DETAILED DESCRIPTION

The subject matter of embodiments of the invention is described withspecificity herein to meet statutory requirements. However, thedescription itself is not intended to limit the scope of this patent.Rather, the inventors have contemplated that the claimed subject mattermight be embodied in other ways, to include different steps orcombinations of steps similar to the ones described in this document, inconjunction with other present or future technologies. Moreover,although the terms “step” and/or “block” may be used herein to connotedifferent elements of methods employed, the terms should not beinterpreted as implying any particular order among or between varioussteps herein disclosed unless and except when the order of individualsteps is explicitly described.

A developer may wish to modify or test the behavior of applicationsafter they are installed on devices. While the developer could provide anew version of an application with modifications, this approach isimpractical where modifications are brief and temporary, such as indebug and testing. Additionally, the user experience is degraded byrequiring download and install of the modified application and thedeveloper is unable to target specific users and/or devices formodifications. In accordance with implementations of the presentdisclosure, the behavior of installed applications can be modifiedremotely by modifying settings of the installed applications. Themodifications can be performed quickly while being unobtrusive to theuser experience. Furthermore, specific devices and/or users can betargeted for different settings.

Accordingly, embodiments of the present invention are directed to remotemanagement of application settings. In some aspects of the presentdisclosure, a managed device is provided with localized remote settingsby a remote settings service. Localized remote settings can correspondto remote settings for applications that are stored on managed devicesafter having been externally provided to the managed devices. Localizedremote settings can be applied to applications by the managed devices.By modifying localized remote settings using a remote settings service,different settings can be applied to the applications by the manageddevices so as to remotely manage the settings.

In some implementations, management of remote settings can includeevaluating localized remote settings on the managed devices. Forexample, the localized remote settings associated with an application(s)can be compared to reference remote settings by a remote settingsservice to check whether or not the localized remote settings correspondto the reference remote settings that are intended to be provided to oneor more managed devices for the application(s). If the localized remotesettings correspond to the reference remote settings, the remotesettings service may refrain from sending or transmitting referenceremote settings to the managed device. Otherwise, the remote settingsservice may send or transmit reference remote settings to the manageddevice, which can replace one to all of the localized remote settings.

In further aspects of the present disclosure, comparing localized remotesettings to reference remote settings can be accomplished by comparingrespective hash values that correspond to the localized and referenceremote settings. In this respect, a client-side hash value is generatedbased on localized remote settings for an application on a manageddevice. The client-side hash value is sent or transmitted from themanaged device to the remote settings service in a networkcommunication. The network communication can be sent or transmitted tothe remote settings service by the application, for example, as part ofa startup routine of the application. In some cases, the networkcommunication is sent or transmitted each time the application startsup, or launches. A server-side hash value is generated based onreference remote settings for the application. The server-side hashvalue is compared to the client-side hash value received in the networkcommunication. A response to the network communication can be based onresults of the comparison.

In certain respects, if the comparison indicates a mismatch between theserver-side hash value and the client-side hash value, the remotesettings service may send at least some of the reference remote settingsto the managed device in a response to the network communication. Themanaged device may implement any portion of or all of reference remotesettings that are received from the remote settings service.Furthermore, any portion of the received reference remote settings maymodify or replace the localized remote settings. If the comparisonindicates a match between the server-side hash value and the client-sidehash value, the remote settings service may refrain from sending atleast some of the reference remote settings to the managed device. Insome cases, the remote settings service may send a response to thenetwork communication that does not include any of the reference remotesettings, for example to close a connection to the managed device.

In other aspects of the present disclosure, one or more specific manageddevices, and/or one or more groups of managed devices can be targetedfor management of remote settings. A group of managed devices may bedefined by the managed devices sharing one or more attributes. Byaccounting for attributes, managed devices may be sent or transmitteddifferent reference remote settings and have different resultantlocalized remote settings for the same application. In some cases, thetargeting can be accomplished by assigning at least one attribute to atleast some settings of reference remote settings, where the attributescorrespond to target devices of the at least some settings. A targetdevice for a setting can correspond to a device that is intended to orotherwise designated to implement the setting.

A network communication to a managed device may indicate attributes thatare assigned to settings in reference remote settings to the manageddevice. The network communication may include the at least some settingsand the managed device may implement ones of the at least some settingsthat have attributes corresponding to the managed device. The networkcommunication may include any combination of the at least some settings,the at least some settings that have attributes corresponding to themanaged device, and all of the remote settings for an application. Thus,in some cases, the managed device may not implement all of the remotesettings that it receives based on whether or not the assignedattributes correspond to the managed device. Doing so can allow fortargeted management of remote settings services for managed deviceswithout necessarily having access to attributes of the managed devicesat a remote settings service.

In further aspects of the present disclosure, the remote settingsservice can complete processing of a network communication, such as anetwork communication that includes a client-side hash value from amanaged device, after sending a response to the network communication.For example, the network communication can include encoded payload dataand the remote settings service can complete decoding and/or otherprocessing of the encoded payload data after sending the response to thenetwork communication. In this way, local remote settings on manageddevices can be managed quickly with minimal impact on the operation ofthe managed devices.

In further respects, the remote settings service can receive a networkcommunication from a managed device, the received network communicationcomprising a client-side hash value. The remote settings service canidentify settings for an application on the managed device in responseto the receiving of the network communication. For example, the settingscan be identified based on an application identifier of otherinformation in the network communication and/or based on the manageddevice that sent the network communication. The identified settingscomprise configuration instructions for the application. Based on acomparison between the received client-side hash value and a server-sidehash value that corresponds to the identified settings, the remotesettings service can transmit at least some of the identified settingsto the managed device.

Turning now to FIG. 1 , a diagram is provided illustrating an exemplarysystem 100 in which some implementations of the present disclosure maybe employed. It should be understood that this and other arrangementsdescribed herein are set forth only as examples. Other arrangements andelements (e.g., machines, interfaces, functions, orders, and groupingsof functions, etc.) can be used in addition to or instead of thoseshown, and some elements may be omitted altogether. Further, many of theelements described herein are functional entities that may beimplemented as discrete or distributed components or in conjunction withother components, and in any suitable combination and location. Variousfunctions described herein as being performed by one or more entitiesmay be carried out by hardware, firmware, and/or software. For instance,various functions may be carried out by a processor executinginstructions stored in memory.

Among other components not shown, system 100 includes a number ofmanaged devices, such as managed devices 102 a and 102 b through 102 n,a number of administrator devices, such as administrator devices 104 athrough 104 n, remote settings service 106, and application distributionsystem 112. It should be understood that system 100 shown in FIG. 1 isan example of one suitable computing system. Each of the componentsshown in FIG. 1 may be implemented utilizing any type of computingdevice, such as computing device 600, later described with reference toFIG. 6 , for example. The components may communicate with each other vianetwork 108, which may include, without limitation, one or more localarea networks (LANs) and/or wide area networks (WANs). Such networkingenvironments are commonplace in offices, enterprise-wide computernetworks, intranets, cellular networks, and the Internet.

It should be understood that any number of managed devices,administrator devices, application marketplaces, and remote settingservices may be employed within system 100 within the scope of thepresent disclosure. Each may comprise a single device or multipledevices cooperating in a distributed environment. For instance, remotesettings service 106 may be provided via multiple devices arranged in adistributed environment that collectively provide the functionalitydescribed herein. As a specific example, remote settings service 106 caninclude a database management system based on the Erlang programminglanguage, such as an Mnesia distributed DataBase Management System(DBMS). Any of the various data described herein can be stored andmaintained in the database management system. Additionally, othercomponents not shown may also be included within the distributedenvironment.

Managed devices 102 a and 102 b through 102 n and administrator devices104 a through 102 n can also be referred to as client-side devices.Remote settings service 106 may be on the server-side of system 100,while the client-side devices are on the client-side of system 100. Aclient-side device might take on a variety of forms, such as a personalcomputer (PC), a laptop computer, a mobile phone, a smartphone, asmartwatch, a tablet computer, a wearable computer, a personal digitalassistant (PDA), a server, an MP3 player, a global positioning system(GPS) device, a video player, a handheld communications device, aworkstation, any combination of these delineated devices, or any othersuitable device.

Application distribution system 112 provides features for managingapplications that typically include discovering, downloading, andupdating the applications. Examples of application distribution system112 include application marketplaces, such as Apple® App Store℠, Apple®Mac App Store℠, Google Play™ store, Windows Phone® Store, andMicrosoft's Apps for Windows®. As another example, applicationdistribution system 112 could be a beta testing system, such asTestFlight®. Developers can utilize application distribution system 112to distribute applications to managed devices 102 a and 102 b through102 n. The applications can correspond to applications 110 a, 110 b,and/or other applications on the managed devices.

The feature set of application distribution system 112 can be limitedand typically does not extend beyond basic application distribution.Furthermore, feature sets can vary between application distributionsystem 112 and other application distribution systems, which canintroduce the risk of fragmenting a developer's user base orcomplicating application design, particularly in the cross-platformenvironment. For example, while managed device 102 a could be an iPhonehaving access to Apple App Store, managed device 102 b could be anAndroid device, which does not typically have access to Apple App Store.As such, developers may seek other application management solutions,such as remote settings service 106 to overcome any of the variouslimitations of application marketplaces and other applicationdistribution systems.

Furthermore, even where application distribution system 112 is notemployed by a developer, application management solutions, such asremote settings service 106, can be highly beneficial to developers byproviding feature sets that free up development time for corefunctionality of the applications.

Remote settings service 106 may be employed by a developer or anotherparty to assist in managing one or more of the developer's applications.In particular, remote settings service 106 can be utilized to manageremote settings for one or more applications, such as applications 110 aand 110 b. The developer and/or another party can manage the remotesettings by utilizing any of administrator devices 104 a through 104 n,or another administrator device, to act as an administrator of theremote settings for one or more applications. While administratordevices 104 a through 104 n are depicted distinctly from managed devices102 a and 102 b through 102 n, in some implementations, a managed devicecan be utilized as an administrator device.

Administrators can utilize administrator devices to manage remotesettings for applications on managed devices through remote settingsservice 106. While administrator devices 104 a through 104 n aredepicted as client-side devices, any of those administrator devices orcomponents thereof could be incorporated into the remote settingsservice.

Although many approaches to interfacing with remote settings service 106are within the scope of the present disclosure, in the example shown inFIG. 1 , a developer can easily include remote settings features in anapplication by incorporating one or more libraries, such as library 120into the application. As shown, application 110 a includes library 120,which can correspond to (e.g. be from) a software development kit (SDK).Library 120 includes various functions and routines for interfacing withremote settings service 106, as well as for applying settings toapplications that incorporate the library. Although not shown,application 110 b could also include library 120. Furthermore, differentversions of library 120 may be included in any of the various manageddevices in system 100.

As mentioned above, remote settings for applications that are stored ona managed device can be referred as localized remote settings. Localizedremote settings are distinguished from applied remote settings in thatnot all of the localized remote settings are necessarily applied to anapplication. Each managed device, such as managed devices 102 a and 102b through 102 n can include one or more sets of localized remotesettings. In the present example, application 110 a is shown as havinglocalized remote settings 118 a on managed device 102 a, localizedremote settings 118 b on managed device 102 b, and localized remotesettings 108 n on managed device 102 n. Each instance of application 110a can have the same set and/or sets of localized remote settings or oneto all of the set or sets can be different with respect to differentapplication instances. Sets of localized remote settings can be providedto the managed devices by remote settings service 106.

In some aspects of the present disclosure, by providing localized remotesettings for applications to the managed devices, a developer canconfigure settings for applications outside of application distributionsystem 112 or other application distribution systems. Thus, settings foran application can be modified without necessarily requiring thedistribution of a modified version of the application. In some cases,applications are distributed by application distribution system 112 orother application distribution systems with default settings. Thedefault settings can be changed by providing localized remote settingsto managed devices utilizing remote settings service 106. However,applications could also be distributed without default settings and canlater be provided with settings from localized remote settings viaremote settings service 106.

Remote settings service 106 can be utilized to manage a variety ofsettings for applications on managed devices. A setting can include oneor more values that modify the behavior of one or more applications. Forexample, a setting may enable or disable the display of advertisementsin an application, logging in an application, and/or one or more paidfeatures in an application. One or more routines and/or function maycorrespond to a paid feature. Whether or not a paid feature should beactivated may be identified based on an attribute, such as any ofattributes 116 a. A paid feature may be activated for a period of time,such that a setting may be deactivating after expiration of asubscription or time period. Information that determines whether or notthe paid feature should be activated or deactivated by a setting couldbe tracked and/or stored in remote settings service 106. Another settingmay change the background color of a home screen of an application. Asetting can have a format such that the application can identify amanner in which to apply the setting. As an example, the setting couldinclude one or more key-value pairs. An application can have preexistingcode that can identify how to apply the value to the application basedon a corresponding key. A setting may also be referred to as aconfiguration instruction, which can be defined by one or more key-valuepairs. Values can correspond to configurations for an application, andthe application can have routines and/or functions that determine how toapply those values to the application based on identifying one or morekeys in the setting. For example, the application may be programmed torecognize the one or more keys and apply values of the keys using one ormore routines and/or functions that correspond to or are otherwiseassociated with the keys.

In some instances, a setting can enable or disable a routine of one ormore applications. A routine can comprise one or more functions of anapplication. An application can be distributed to a managed device witha plurality of routines. For example, each instance of application 110 aincludes routines 114 in FIG. 1 and library 120 also includes one ormore routines. Application 110 b can be distributed with a differentgroup of routines than application 110 a. Also, in some instancesroutines may be added to an application after distribution thereof, forexample, by remote settings service 106, and could be a part oflocalized remote settings 118 a, 118 b, or 118 c. By enabling ordisabling any combination of the routines of an application, certainfeatures of the application can be toggled on or off after distributionof the application.

A specific example of a routine is a logging routine. A logging routinecan correspond to a routine that includes one or more functions that loginformation on a managed device. For example, routines 114 couldcomprise one or more logging routines that can log information generatedby executing application 110 a, or otherwise available on a manageddevice. By enabling a logging routine, a developer can be provided withone or more logs of the logged information, for example, for debuggingan application on a managed device. The logging routine could later bedisabled, for example, when the developer has finished debugging theapplication, or where logging is otherwise no longer desired.

In addition to or instead of enabling or disabling any of variousroutines on the managed devices, remote settings service 106 can beutilized to configure any of the various routines. A setting thatconfigures a routine can be any setting that modifies operation of theroutine. In some cases, multiple settings may modify operation of thesame routine. In some implementations, a setting can modify operation ofa routine by providing one or more variables to one or more functions ofthe routine. In addition, or instead, a setting can modify operation ofa routine by enabling or disabling any of the various functions thatmake up the routine.

As a specific example, where a routine is a logging routine, a variablecould be provided by a setting that selects a logging level of thelogging. The variable could be a value that corresponds to the logginglevel. Higher logging levels may cause functions of the routine to logadditional information relative to lower logging levels. As anotherexample, one or more variables could select any combination of variouslogging functions of a logging routine. Each of the logging functionsmay log different information on a managed device. As another example, asetting could configure a user interface routine by enabling ordisabling a function that presents a button on a user interface of anapplication. When the button is enabled, a user of a managed device maytoggle the button to selectively enable or disable a logging routine orother routine on the managed device.

Application distribution system 112 and other application distributionsystems typically distribute applications to managed devices such thatinstances of the same application deployed on different managed deviceshave the same settings. In some implementations, by utilizing remotesettings service 106, instances of the same application on differentmanaged devices can optionally be provided with different settings. Forexample, the instance of application 110 a on managed device 102 a canhave at least one different set of localized remote settings than theinstance of application 110 a on managed device 102 b.

The foregoing can be accomplished by taking into account any of variousattributes of applications, managed devices that include theapplications, and/or users of the managed devices or applications. Forexample, FIG. 1 indicates that managed device 102 a has attributes 116a, managed device 102 b has attributes 116 b, and managed device 102 nhas attributes 116 n. An example of an attribute of a managed device isa platform of the managed device. Platforms of managed devices 102 a,102 b, and 102 n can be any combination of Android™, iOS®, and WindowsPhone®, as some examples. Another example is a model of a manageddevice, such as Nexus 5, iPhone 5, and Samsung GT-I9300. Other examplesinclude a carrier (e.g. T-mobile®, AT&T®, Sprint®), a connection type(e.g. WiFi, UMTS, LTE), an operating system version (e.g., 4.3, 4.4.2,7.1), an IP address, a location (e.g. United States, China, Japan,Germany), a battery level, a storage capacity level, a capability, adevice identifier, a serial number, a machine address code (MAC)address, and many more.

Examples of attributes of applications include an application version(e.g. version number and/or version name), an install date, a runtime, alanguage, an application identifier, an SDK version, a binary name, andmany more. Certain attributes may be of a user of an application and/ora managed device. A user can have an associated user profile thatcomprises various attributes. Attributes for a user can include a useridentifier, such as a universally unique identifier (UUID), an age, agender, a payment status or history, a user account status, and manymore.

Attributes can be defined by one or more values and may have predefinedschemas, such that values of attributes are consistent amongst manageddevices having remote settings being implemented utilizing remotesettings service 106. Some schemas could be carried out by library 120and others could be carried out by routines 114, as an example. In someinstances, at least some remote settings can be applied to an instanceof an application on a managed device based on any of the variousattributes or combination of attributes. For example, one setting orgroups of settings may be applied to or not applied to a managed devicebased on the managed device corresponding to one or more designatedattributes. Thus, for example, managed device 102 a may have one settingapplied to its instance of application 110 b, whereas managed device 102b does not have the same setting applied to its instance of application110 b based on one or more attributes. In this way, settings can be madespecific to one or more groups of or one or more specific ones ofmanaged devices or users for the same application.

In some implementations, remote settings service 106 provides remotesettings to a managed device at which the settings are stored aslocalized remote settings. The remote settings provided by remotesettings service 106 can include assignments between attributes and atleast some settings therein. The assignments can define target devicesof the at least some settings. A target device for a setting cancorrespond to a device that is intended to implement the setting. Byproviding one or more indications of one or more attributes beingassigned to one or more settings to a managed device, the managed devicecan determine whether or not to apply any of the various settings thatmay be provided by remote settings service 106. In other words, themanaged device can determine whether or not it is a target device. Insome cases, a managed device may be in a better position for thisdetermination than remote settings service 106, as many attributes canbe determined quickly and accurately at the managed device.

Thus, remote settings service 106 does not necessarily need to store andmaintain comprehensive indexes of attribute information for the manageddevices. Furthermore, one to all of the same localized remote settingscan be provided to different managed devices, while still allowing fordifferent settings to be applied to the managed devices. This can allowfor remote settings service 106 to quickly respond to networkcommunications from the managed devices with remote settings, as remotesettings service 106 can assign attributes to at least some settings ofremote settings that are eventually sent to the managed devices prior toreceiving the network communications and without having to query themanaged devices for attribute information.

While in various implementations, one or all of the same localizedremote settings are provided to different managed devices, for example,to different instances of the same application on the managed devices,at least some of the localized remote settings that are provided couldbe different from one another. For example, remote settings service 106could provide different settings to the managed devices based on any ofthe various attributes described herein. The attributes that correspondto a managed device can be communicated to remote settings service 106by the managed device and optionally can be stored and maintained byremote settings service 106. This approach may be especially suitablefor attributes that do not typically change or frequently change overtime, such as for the lifetime of the managed device. Some specificexamples include a model of the managed device and a platform of themanaged device, and various attributes that are descriptive of hardwarecomponents of the managed device.

Remote settings service 106 can be employed for receiving, providing,updating, and/or modifying at least one localized remote setting for atleast one application on a managed device at any time. Furthermore, themanaged device may apply any of the various localized settings at anytime. Thus, changes to sets of localized remote settings may or may notcause immediate changes to corresponding applied remote settings. Whileat least some localized remote settings could be applied to anapplication proximate to and in response to receipt of localizedsettings, others could be applied regardless of when localized settingsare received.

In some implementations, remote settings service 106 can provide remotesettings to a managed device responsive to a request from the manageddevice. A request from a managed device can be made at any time and canbe made by an application, such as application 110 a, which may employlibrary 120 to make the request. Requests can follow any of a variety ofprotocols. In some instances, requests and responses to requests aremade in accordance with HyperText Transfer Protocol (HTTP). For example,a request can be an HTTP POST request. As such, the request couldcomprise a uniform resource locator (URL) that includes header andpayload data.

In some instances, a request is made based on the application beingactive on a managed device, as opposed to being suspended or otherwiseinactive. Also, a request can be made as part of a routine, such asroutines 114 and/or routines of library 120. In some aspects of thepresent disclosure, a request is part of a startup routine of anapplication, which could be from library 120 and/or routines 114. Astartup routine can generally be a routine that executes based upon anapplication becoming active, such as based on being launched orreturning from suspension or other levels of reduced activity. In somecases, a startup routine executes unconditionally upon the applicationlaunching. In other cases, a startup routine may execute based on beinglaunched for the first time after an install of the application. In somecases, the request is sent or transmitted each time the applicationstarts up, or launches. By being incorporated into a startup routine ofan application, a request can be made at a time when the application isactive and will likely remain receptive to receiving and/or implementingremote settings from remote settings service 106. Therefore, resourcesof remote settings service 106 can be preserved by increasing thelikelihood that any responses to the request are successful.Furthermore, a user of the application would likely be more tolerant ofany possible delay or other impact in application performance duringstartup, as many users are accustomed to applications loading atstartup.

In addition, or instead, in some instances, remote settings service 106can provide remote settings to the managed device without necessarilyfirst receiving a request from the managed device. For example, one ormore remote settings may be provided to a managed device based onreceiving a modification to reference remote settings from anadministrator, which may be provided from an administrator device. Asanother example, the administrator may prompt remote settings service toprovide one or more remote settings to one or more managed devices.These and other features of remote settings service 106 are described inadditional detail with respect to FIG. 2 .

Referring to FIG. 1 with FIG. 2 , FIG. 2 shows remote settings service206, which can correspond to remote settings service 106 in FIG. 1 .Remote settings service 206 includes service controller 230, interfacecomponent 232, communications processor 234, and reference settingsmanager 236. Service controller 230 is configured to direct operationsfor management of remote settings for remote settings service 206, whichcan include routing information between any of the variousaforementioned constituents of remote settings service 206. In doing so,settings can be remotely managed for applications on managed devices byway of an interface component of remote settings service 106.

Interface component 232 includes network interface 240 and administratorinterface 242. Network interface 240 is configured to receive incomingnetwork communications for remote settings service 206, such ascommunication 244 a provided to service controller 230. Networkinterface 240 is also configured to send outgoing communications, suchas network communication 244 b from service controller 230. The incomingand outgoing communications can be from managed devices or administratordevices. Furthermore, service controller 230 can direct interfacecomponent 232 in communicating with the managed devices and/or theadministrator devices so as to manage remote settings on any combinationof the managed device by way of the incoming and outgoing networkcommunications, such as communications 244 a and 224 b, respectively.

With respect to administrator devices, network interface 240 cancooperate with administrator interface 242 in allowing foradministrators to interact with remote settings service 206 formanagement of remote settings for applications on managed devices. Insome aspects of the present disclosure, an administrator can utilizeadministrator interface 242 to provide reference remote settings, suchas reference remote settings 252 to remote settings service 206. Asdescribed previously, reference remote settings can correspond tosettings for applications that are intended to be provided to one ormore managed devices for the applications (e.g. as designated by one ormore administrators). However, reference remote settings are notnecessarily on the one or more managed devices at any given time. Forexample, reference remote settings can change after being provided tothe one or more managed devices, and therefore, any changes may later beprovided to the one or more managed devices.

In this regard, the administrator can provide any combination ofconfiguration instructions 248 (e.g. values for settings) and settingsdefinitions 250 (e.g. keys for settings) as inputs to remote settingsservice 206 via administrator interface 242. The foregoing informationmay be provided by an administrator, for example, by way of a webbrowser or other application on an administrator device that is capableof communicating with administrator interface 242. The web browser orother application can present information to the administrator that isbeing maintained by remote settings service 206 in order to aid theadministrator in generating configuration instructions 248 and settingsdefinitions 250. For example, one or more current settings of thereference settings could be presented with options or other means tomodify the settings.

Service controller 230 can provide reference settings manager 236 withconfiguration instructions 248 and/or settings definitions 250 that arereceived from administrator interface 242. Reference settings manager236 can manage remote settings, such as reference remote settings 252based on the received configuration instructions 248 and/or settingsdefinitions 250. Settings definitions 250 comprises information thatdefines one or more settings for reference remote settings 252 and mayoptionally replace one to all of reference remote settings 252. In someimplementations, each settings definition includes at least one key fora key-value pair. The one or more settings that are defined may have oneor more default attributes, values, and/or configurations provided bythe administrator.

While in some implementations, remote settings service 206 canoptionally receive settings definitions from an administrator, in somecases, at least some settings are provided or defined by remote settingsservice 206. For example, remote settings service 206 may have one ormore default settings definitions or presets that could be available toany of the various applications that have remote settings being managedusing remote settings service 206. One specific example could be one ormore settings definitions that correspond to one or more loggingroutines of the applications. In various implementations, the default orpresets that are available for reference remote settings correspond toone or more routines of library 120 (e.g. routines that are provided byan SDK).

Configuration instructions 248 can correspond to instructions thatconfigure settings of reference remote settings, such as referenceremote settings 252. In some implementations, a setting comprises akey-value pair and optionally one or more assigned attributes. Forexample, as shown, reference remote settings 252 comprise key-valuepairs 254 and assigned attributes 256. Settings can be configured, forexample, by configuring the values and/or assigned attributes of thesettings. In some cases, configuration instructions provide one or morevalues and/or assigned attributes for one or more settings thereby usedto configure the one or more settings.

An administrator can have an administrator account, or profile, whichcan be included in administrator accounts 260, shown in FIG. 2 . In someimplementations, reference settings manager 236 can utilizeadministrator accounts 260 in managing reference remote settings. Anadministrator account can define privileges, or rights, of anadministrator with respect to one or more applications, one or moreremote settings, and/or one or more sets of remote settings. Referencesettings manager 236 can enforce those privileges, or rights, withrespect an administrator's ability to view, modify, update, delete, addto, or otherwise alter reference remote settings (e.g. provide newvalues of one or more settings), members of one or more sets of remotesettings, which reference remote settings and/or sets of referenceremote settings are to be provided to an application and/or a manageddevice (e.g. provide new attribute assignments for settings), and manymore remote management abilities of administrators, including thosedescribed herein.

Privileges can correspond to any of a variety of potential managementabilities and different administrators may have at least some privilegesin common. Privileges may be assigned to administrators at theapplication level. For example, one or more administrators may beassigned a privilege to manage settings for application 110 a, whereasone or more other administrators are not assigned a privilege to managesettings for application 110 a, but are assigned a privilege to managesettings for at least application 110 b.

Privileges could also be assigned to administrators at the settingslevel with respect to an application. For example, although multipleadministrators have at least some management privileges with respect toapplication 110 a, only some of those administrators may be permitted toview, delete, change, or otherwise manage one or more designatedsettings and/or designated sets of settings for application 110 a, whileothers of those administrators may have management rights with respectto one or more other settings.

Additionally, privileges for managing settings for an application canfurther be assigned at the ability level with respect to management ofsettings. As an example, one administrator may have privileges to view,or read from, one setting, but not alter, or write to, that setting.Another administrator might be able to both read from, and write to, thesetting.

By implementing administrator accounts and privileges, referencesettings manager 236 can effectively provide remote management servicesfor multiple developers or other parties, who each may have one or moreassociated applications. Thus, in FIG. 2 , an administrator account of adeveloper can have privileges with respect to reference remote settings252, by way of example. The same administrator account can haveprivileges with respect to multiple sets of reference remote settings.The sets of reference remote settings can be for various applicationsthat are associated with the administrator account and may be owned bythe developer. For example, in FIG. 1 , one set of reference remotesettings may be for application 110 a, and another set of referenceremote settings may be for application 110 b.

In remotely managing settings, reference settings manager 236 candetermine whether or not to send reference remote settings to a manageddevice. Reference remote settings can correspond to settings forapplications that are intended to be provided to one or more manageddevices for the applications (e.g. as designated by one or moreadministrators). At least some reference remote settings can be sent toa managed device responsive to a request from the managed device, asdescribed earlier, or can be sent to the managed device independent ofhaving received a request. A request can correspond to a networkcommunication sent by the managed device to remote settings service 206.Reference settings manager 236 may employ a server-side hash value, suchas server-side hash value 270, to determine whether or not to respond tothe request with reference remote settings, as described in further withrespect to FIG. 3 .

FIG. 3 depicts exemplary network communication 344 that can correspondto a request sent by a managed device, in accordance with someimplementations of the present disclosure. For exemplary purposes, themanaged device will be described with respect to managed device 102 a inFIG. 1 , however, other managed devices can send similar requests.Network communication 344 can correspond to network communication 244 ain FIG. 2 .

As indicated by FIG. 3 , a network communication can comprise aclient-side hash value, such as client-side hash value 362, which cancorrespond to any of client-side hash values 162 a, 162 b, and 162 n inFIG. 1 . A client-side hash value can correspond to one or more remotesettings on the managed device sending the request, such as localizedremote settings that are associated with an application. For example,client-side hash value 162 a may correspond to remote settings that areutilized in applying settings to application 110 a on managed device 102a, which may be the most recently received reference remote settingsfrom remote settings service 206 for application 110 a (e.g. localizedremote settings 118 a) with respect to managed device 102 a.

In some implementations, the managed device sending the requestgenerates the client-side hash value from the one or more remotesettings. For example, managed device 102 a can hash localized remotesettings 118 a to generate client-side hash value 162 a. In otherimplementations, the managed device does not generate the client-sidehash value, and may have previously received the client-side hash valuefrom a network communication from remote settings service 206(optionally in a response to network communication 344). For example,managed device 102 a may have previously received client-side hash value162 a from remote settings manager 236. Furthermore, client-side hashvalue 162 a may have been received along with and/or in association withany reference remote settings that were hashed to generate client-sidehash value 162 a (e.g. hashed by remote settings service 206).

Client-side hash values can be generated utilizing any suitable hashalgorithm. An example of a suitable hash algorithm is an MD5 ormessage-digest hash algorithm or a secure hash algorithm (SHA).Furthermore, client-side hash values can be generated at any suitabletime. Where a managed device generates client-side hash values,generation can occur responsive to receipt of reference remote settingsfrom remote settings service 206. Thus, for example, managed device 102a can generate client-side hash value 162 a responsive to receiving thereference remote settings that correspond to localized remote settings118 a. In addition, or instead, managed device 102 a may generateclient-side hash value 162 a as part of a startup routine. In caseswhere managed device 102 a does not include localized remote settings,such as on initial launch after install, client-side hash value 162 amay be given a default value or may be generated from default localizedremote settings.

Remote settings service 206 can receive the request (e.g. networkcommunication 344) from the managed device. Remote settings service 206can also generate server-side hash values, such as server-side hashvalue 270 based on any to all of reference remote settings, such asreference remote settings 252, which are associated with an application.Server-side hash values can be generated at any suitable time. It isnoted that in some cases, the server-side hash value may be generated byan administrator device or otherwise be generated outside of remotesettings service 206.

In some implementations, a server-side hash value is generated prior toreceipt of a network communication of the request. For example,server-side hash value 270 can be generated and/or updated in responseto any modifications made to reference remote settings that are hashedto generate server-side hash value 270, for example to replace aprevious version of the server-side hash value with a new server-sidehash value. In doing so, the server-side hash value will typically beavailable upon receipt of a corresponding network communication, such asnetwork communication 344. This can aid in rapidly providing anyresponse that may be made to the request.

A server-side hash value is generally hashed utilizing the same hashingalgorithm as a corresponding client-side hash value, such as the MD5hash algorithm or the SHA. Thus, the two hash values should match if oneor more settings (e.g. localized remote settings 118) hashed to generateclient-side hash value 362 match one or more reference remote settings(e.g. reference remote settings 252) hashed to generate the server-sidehash value. The hash values can be compared to one another by referencesettings manager 236 to determine whether or not there is a match. Amatch can indicate that the managed device that sent the request has themost current reference remote settings that are intended for anapplication and/or the managed device. Based on a match, remote settingsservice 206 may refrain from responding to the request. In otherimplementations, remote settings service 206 may respond using anoutgoing communication, such as network communication 244 b, but mayrefrain from sending any reference remote settings to the managed devicein the response based on the match.

A mismatch indicated by the comparison can convey that the manageddevice that sent the request does not have the most current referenceremote settings. This can occur, for example, where the managed devicelacks any localized remote settings, such as upon initial launch of anapplication after install. As another example, while localized remotesettings that are hashed to form the client-side hash value may haveinitially been identical to the reference remote settings thatcorrespond to the localized remote settings, changes could havesubsequently been made to the reference remote settings, for example, byan administrator. As such, the client-side hash value may not match theserver-side hash value, indicating that the localized remote settingsare out of date or otherwise in need of modification. Thus, remotesettings service 206 can send the reference remote settings to themanaged device based on the comparison between the server-side hashvalue and the received client-side hash value to update the localizedremote settings on the managed device. More particularly, the sendingmay be based on the comparison indicating a mismatch between theserver-side hash value and the client-side hash value. However, it isnoted that the sending may still be performed despite a match betweenthe server-side hash value and the client-side hash value, or based onthe match. For example, an administrator may override the sending basedon the mismatch.

As many different reference remote settings may be available toreference settings manager 236, information may be provided to referencesettings manager 236, such that the service-side hash value that isutilized in the comparison corresponds to the proper reference remotesettings for the managed device that sent the request. In some cases, atleast some of this information may be provided by the managed device,such as in the network communication that corresponds to the request.Reference remote settings and/or server-side hash values hashed fromthose reference remote settings can be indexed by or otherwiseassociated with any of this information. Thus, for example, server-sidehash value 270 can be retrieved or generated for a comparison withclient-side hash value 362 by accessing an index entry corresponding toapplication 110 a or otherwise retrieving application 110 a based on theinformation.

In some cases, the information could comprise an application identifier,such as application identifier 364, such that the server-side hash valueis utilized in the comparison based on the application identifier (e.g.,the settings that correspond to the server-side hash value can beidentified using the application identifier). As such, theaforementioned indexing could be by application identifiers. Anapplication identifier can correspond to an identifier that can beutilized to identify an application amongst a plurality of applications.In some instances, the information can comprise other attributesutilized to select the server-side hash value in addition to or insteadof an application identifier. Such attributes can correspond to any ofthe various attributes described with respect to attributes 116 a, 116b, and 116 n.

By selecting server-side hash values for comparison based on one or moreattributes, different reference remote settings can be compared toand/or subsequently provided to managed devices based on thoseattributes. Thus, for example, utilizing an application identifier, acomparison could utilize a server-side hash value based on anapplication that is identified from a network communication based on theapplication identifier. Thus, for example, a user identifier (ID) couldbe associated with reference remote settings, such that an administratorcan individually designate the reference remote settings for that userID (e.g. a UUID). This aspect of the present disclosure can be usefulfor debugging applications. Furthermore, by associating referencesettings with additional attributes or more generic attributes than aunique identifier, groups of managed devices can be targeted by theadministrator for the reference remote settings. Amongst many potentialuses, this feature can be used for A/B testing an application amongstvarious managed devices.

As indicated above, at least some of the attributes may have beenpreviously provided to remote settings service 206 by managed devices,or by another source, such as by administrators. Remote settings service206 can manage and maintain such information, which may be stored inassociation with corresponding managed devices. For example, any ofattributes 116 a of managed device 102 a can be stored in associationwith managed device 102 a and any of attributes 116 b of managed device102 b can be stored in association with managed device 102 b. Inaddition, or instead, any of the various attributes may be included inthe network communication corresponding to a request by a manageddevice.

By including one to all of any attributes or other information that isutilized to select or generate the server-side hash value 270 in thenetwork communication from the managed device, the attributes can bemade more readily available and are more likely to be up to date, ascompared to attributes maintained by remote settings service 206. Asexamples, an application version identifier could be included anddifferent reference remote settings can be associated with differentversions of the same application. Another example is an administratorID, however, the application identifier could also be associated with anadministrator in remote settings service 206.

As indicated by FIG. 3 , a managed device (e.g. managed device 102 a)can determine which communication type ID to include in a networkcommunication and include that communication type ID in the networkcommunication. For example, the managed device may select communicationtype ID 366 to include in network communication 344. A communicationtype ID can identify the type of network communication or request thatthe managed device is providing to remote settings service 206. In theexample shown, communication type ID 366 identifies networkcommunication 344 as a remote settings type communication.Communications processor 234 can extract the communication type ID froma network communication and can process the remainder of the networkcommunication in accordance with processing instructions that areassociated with the communication type ID. Furthermore, different valuesof the communication ID could indicate which attributes are included inthe network communication and/or different variations of remote settingstype communications.

A network communication of a request can further comprise encodedpayload data, such as encoded payload data 368. Encoded payload data cangenerally correspond to data that is in an encoded format. The encodedpayload data can be decoded in communications processor 234 processingthe network communication. The decoded data can comprise a variety ofinformation, which is not necessarily, but may be employed for remotelymanaging settings of managed devices. In some cases, the encoded payloaddata includes any of various attributes, such as attributes 116 a, whichcan be stored in association with managed device 102 a for management ofremote settings on that device. Other examples include loggedinformation from the managed device, which could be from a loggingroutine, as described above. Thus, encoded payload data 368 couldinclude one or more debug logs. Encoded payload data 368 could alsoinclude one or more crash logs, clickstream logs, or other types ofevent based logs.

In some variations, communications processor 234 completes processing ofthe network communication corresponding to the request after the sendingof at least some reference remote settings to the managed device in aresponse to the request. In doing so, remote settings service 206 canmore rapidly respond to the managed device that sent the request,allowing for more unobtrusive and transparent management of remotesettings on the managed device.

In some instances, communications processor 234 completes decoding ofencoded payload data (such as encoded payload data 368) after thesending of at least some reference remote settings to the requestingmanaged device. Doing so can save significant processing time that wouldotherwise delay the sending. For example, the encoded payload data couldcomprise kilobytes or more of data and take seconds to process. Theencoded payload data can comprise key-value pairs. In some cases,decoding of the encoded payload data includes parsing and/or otherwiseanalyzing and processing the key-value pairs. The encoded payload datacan correspond to an encoded data object. Examples include a JavaScriptObject Notification (JSON) encoded object and an Extensible MarkupLanguage (XML) encoded object.

An exemplary approach to remotely managing settings of applications isshown in FIG. 4 . Referring now to FIG. 4 (in combination with FIGS. 1,2, and 3 ), FIG. 4 is a flow diagram showing method 400 for remotelymanaging settings of applications in accordance with implementations ofthe present disclosure. Each block of method 400 and other methodsdescribed herein comprises a computing process that may be performedusing any combination of hardware, firmware, and/or software. Forinstance, various functions may be carried out by a processor executinginstructions stored in memory. The methods may also be embodied ascomputer-usable instructions stored on computer storage media. Themethods may be provided by a standalone application, a service or hostedservice (standalone or in combination with another hosted service), or aplug-in to another product, to name a few.

At block 480, method 400 includes receiving a network communication froma managed device. For example, remote settings service 206 can receivenetwork communication 344 from managed device 102 a. Networkcommunication 344 may have been sent or transmitted by managed device102 a as part of a startup routine from library 120. Networkcommunication 344 can comprise client-side hash value 362, applicationidentifier 364, communication type ID 366, and encoded payload data 368.Managed device 102 a may have generated client-side hash value 162 a,corresponding to client-side hash value 362, by hashing localized remotesettings 118 a. In one example, network communication 344 is an HTTPPOST request and comprises a URL. The URL includes the client-side hashvalue 362, application identifier 364, and communication type ID 366 asraw or plain text.

At block 482, method 400 further includes analyzing at least a portionof the network communication from the managed device. For example,remote settings service 206 can analyze at least a portion of networkcommunication 344. In doing so, upon receiving network communication344, communications processor 234 may extract communication type ID 366.Based on communication type ID 366 indicating a remote settings typecommunication, communications processor 234 can extract client-side hashvalue 362 and application identifier 364 from network communication 344.Reference settings manager 236 can identify network communication 344 ascorresponding to application 110 a based on application identifier 364by retrieving server-side hash value 270 from an index of server-sidehash values that is indexed by corresponding application identifiers.The index may be stored in memory for rapid retrieval of server-sidehash value 270.

Server-side hash value may have been generated by remote settingsservice 206 by hashing reference remote settings 252. Reference remotesettings 252 correspond to application 110 a, for example, based uponbeing assigned to application identifier 364 by an administrator.Reference settings manager 236 can compare client-side hash value 362with server-side hash value 270.

Blocks 484 and 486 represent different options that may be performed,for example, depending on the results of the comparison performed atblock 482. Block 484 may be performed based on or in response to thecomparison performed at block 482 indicating a mismatch betweenserver-side hash value 270 and client-side hash value 362, such thatlocalized remote settings 118 a on managed device 102 a should beupdated to reference remote settings 252. Block 486 may be performedbased on or in response to the comparison performed at block 482indicating a match between server-side hash value 270 and client-sidehash value 362, such that localized remote settings 118 a on manageddevice 102 a do not need to be updated to reference remote settings 252.

At block 484, method 400 includes sending at least some reference remotesettings to the managed device, the at least some reference remotesettings corresponding to an application on the managed device. Forexample, network interface 240 of remote settings service 206 can sendreference remote settings 252 to managed device 102 a, corresponding toapplication 110 a on managed device 102 a via network communication 244b.

After sending network communication 244 b to managed device 102 a,communications processor 234 can complete processing of networkcommunication 344. For example, communications processor 234 cancomplete decoding of encoded payload data 368 into decoded data 272.Decoded data 272 can comprise attributes of managed device 102 a and theattributes can be stored and maintained by remote settings service 206in association with application 110 a, managed device 102 a, and/or anadministrator. In some implementations, the attributes are optionallyutilized target managed devices for application settings. In thesecases, the attributes may optionally be decoded prior to sending networkcommunication 244 b to managed device 102 a, or older versions of theattributes could be employed.

At block 486, method 400 includes refraining from sending at least somereference remote settings to the managed device, the at least somereference remote settings corresponding to an application on the manageddevice. For example, remote settings service 206 can refrain fromsending reference remote settings 252 to managed device 102 a,corresponding to application 110 a on managed device 102 a. However,reference setting service 206 may still send network communication 244 bto managed device 102 a, but without reference remote settings 252. Forexample, network communication 244 b could be a communication to close aconnection to managed device 102 a.

Another exemplary approach to remotely managing settings of applicationsis shown in FIG. 5 . Referring now to FIG. 5 with FIGS. 1, 2, and 3 ,FIG. 5 is a flow diagram showing method 500 for remotely managingsettings of applications in accordance with implementations of thepresent disclosure.

At block 580, method 500 includes receiving, at a managed device,reference remote settings from a remote settings service, the referenceremote settings corresponding to an application on the managed device.For example, managed device 102 a can receive reference remote settings252 from remote settings service 206. Reference remote settings 252 canbe received in network communication 244 b, which could optionally be aresponse to network communication 244 a. Network communication 244 b cancomprise a URL in accordance with HTTP. Reference remote settings 252 innetwork communication 244 b can correspond to an encoded data object,such as a JSON encoded object. Furthermore, reference remote settings252 can correspond to application 110 a, which could optionally beindicated by an application identifier being included in networkcommunication 244 a.

At block 582, method 500 includes applying at least some of thereference remote settings to the application. For example, manageddevice 102 a can apply at least some of the reference remote settings toapplication 110 a. After receiving reference remote settings 252,managed device 102 a may have stored reference remote settings 252 aslocalized remote settings 118, and may have applied at least some ofreference remote settings 252 to application 110 a from localized remotesettings 118. Reference remote settings 252 in network communication 244b may have included indications of attributes that are associated withsettings of reference remote settings 252. Based on the indications,managed device 102 a may apply settings of reference remote settings 252in cases where attributes 116 a satisfy any corresponding attributerequirements of the settings. Furthermore, based on the indications,managed device 102 a may refrain from apply settings of reference remotesettings 252 in cases where attributes 116 a do not satisfy anycorresponding attribute requirements of the settings.

Having described implementations of the present disclosure, an exemplaryoperating environment in which embodiments of the present invention maybe implemented is described below in order to provide a general contextfor various aspects of the present disclosure. Referring initially toFIG. 6 in particular, an exemplary operating environment forimplementing embodiments of the present invention is shown anddesignated generally as computing device 600. Computing device 600 isbut one example of a suitable computing environment and is not intendedto suggest any limitation as to the scope of use or functionality of theinvention. Neither should the computing device 600 be interpreted ashaving any dependency or requirement relating to any one or combinationof components illustrated.

The invention may be described in the general context of computer codeor machine-useable instructions, including computer-executableinstructions such as program modules, being executed by a computer orother machine, such as a personal data assistant or other handhelddevice. Generally, program modules including routines, programs,objects, components, data structures, etc., refer to code that performparticular tasks or implement particular abstract data types. Theinvention may be practiced in a variety of system configurations,including hand-held devices, consumer electronics, general-purposecomputers, more specialty computing devices, etc. The invention may alsobe practiced in distributed computing environments where tasks areperformed by remote-processing devices that are linked through acommunications network.

With reference to FIG. 6 , computing device 600 includes bus 610 thatdirectly or indirectly couples the following devices: memory 612, one ormore processors 614, one or more presentation components 616,input/output (I/O) ports 618, input/output components 620, andillustrative power supply 622. Bus 610 represents what may be one ormore busses (such as an address bus, data bus, or combination thereof).Although the various blocks of FIG. 6 are shown with lines for the sakeof clarity, in reality, delineating various components is not so clear,and metaphorically, the lines would more accurately be grey and fuzzy.For example, one may consider a presentation component such as a displaydevice to be an I/O component. Also, processors have memory. Theinventors recognize that such is the nature of the art, and reiteratethat the diagram of FIG. 6 is merely illustrative of an exemplarycomputing device that can be used in connection with one or moreembodiments of the present invention. Distinction is not made betweensuch categories as “workstation,” “server,” “laptop,” “hand-helddevice,” etc., as all are contemplated within the scope of FIG. 6 andreference to “computing device.”

Computing device 600 typically includes a variety of computer-readablemedia. Computer-readable media can be any available media that can beaccessed by computing device 600 and includes both volatile andnonvolatile media, removable and non-removable media. By way of example,and not limitation, computer-readable media may comprise computerstorage media and communication media. Computer storage media includesboth volatile and nonvolatile, removable and non-removable mediaimplemented in any method or technology for storage of information suchas computer-readable instructions, data structures, program modules orother data. Computer storage media includes, but is not limited to, RAM,ROM, EEPROM, flash memory or other memory technology, CD-ROM, digitalversatile disks (DVD) or other optical disk storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other medium which can be used to store the desired informationand which can be accessed by computing device 600. Computer storagemedia does not comprise signals per se. Communication media typicallyembodies computer-readable instructions, data structures, programmodules or other data in a modulated data signal such as a carrier waveor other transport mechanism and includes any information deliverymedia. The term “modulated data signal” means a signal that has one ormore of its characteristics set or changed in such a manner as to encodeinformation in the signal. By way of example, and not limitation,communication media includes wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, RF,infrared and other wireless media. Combinations of any of the aboveshould also be included within the scope of computer-readable media.

Memory 612 includes computer-storage media in the form of volatileand/or nonvolatile memory. The memory may be removable, non-removable,or a combination thereof. Exemplary hardware devices include solid-statememory, hard drives, optical-disc drives, etc. Computing device 600includes one or more processors that read data from various entitiessuch as memory 612 or I/O components 620. Presentation component(s) 616present data indications to a user or other device. Exemplarypresentation components include a display device, speaker, printingcomponent, vibrating component, etc.

I/O ports 618 allow computing device 600 to be logically coupled toother devices including I/O components 620, some of which may be builtin. Illustrative components include a microphone, joystick, game pad,satellite dish, scanner, printer, wireless device, etc. The I/Ocomponents 620 may provide a natural user interface (NUI) that processesair gestures, voice, or other physiological inputs generated by a user.In some instance, inputs may be transmitted to an appropriate networkelement for further processing. A NUI may implement any combination ofspeech recognition, touch and stylus recognition, facial recognition,biometric recognition, gesture recognition both on screen and adjacentto the screen, air gestures, head and eye tracking, and touchrecognition associated with displays on the computing device 600. Thecomputing device 600 may be equipped with depth cameras, such as,stereoscopic camera systems, infrared camera systems, RGB camerasystems, and combinations of these for gesture detection andrecognition. Additionally, the computing device 600 may be equipped withaccelerometers or gyroscopes that enable detection of motion.

As can be understood, implementations of the present disclosure providefor remote management of application settings. The present invention hasbeen described in relation to particular embodiments, which are intendedin all respects to be illustrative rather than restrictive. Alternativeembodiments will become apparent to those of ordinary skill in the artto which the present invention pertains without departing from itsscope.

From the foregoing, it will be seen that this invention is one welladapted to attain all the ends and objects set forth above, togetherwith other advantages which are obvious and inherent to the system andmethod. It will be understood that certain features and subcombinationsare of utility and may be employed without reference to other featuresand subcombinations. This is contemplated by and is within the scope ofthe claims.

The invention claimed is:
 1. A computer-implemented method for remotelymanaging settings of applications, the method comprising: receiving acommunication from an application on a managed device, the receivedcommunication comprising an application identifier of the applicationand a client-side hash value of a first set of settings of theapplication; identifying a server-side hash value of a second set ofsettings for the application using the application identifier inresponse to the receiving of the communication, the second set ofsettings comprising configuration instructions specific to theapplication identifier and were modified, prior to receiving thecommunication, in response to input provided via a device associatedwith the application to debug the application in association with thesecond set of settings, wherein the device is separate from the manageddevice; and based on a difference of the received client-side hash valueand the server-side hash value, transmitting, to the application on themanaged device, a key-value pair representing a setting associated withthe second set of settings to replace a first setting associated withthe first set of settings causing the application to apply theconfiguration instructions to modify a configuration of the application.2. The computer-implemented method of claim 1, further comprisinggenerating the server-side hash value prior to the receiving of thecommunication.
 3. The computer-implemented method of claim 1, whereinthe configuration instructions comprise a plurality of key-value pairs.4. The computer-implemented method of claim 1, further comprisingcompleting processing of the received communication after thetransmitting of the key-value pair representing the setting associatedwith the second set of settings.
 5. The computer-implemented method ofclaim 1, further comprising completing decoding of encoded payload dataof the received communication after the transmitting of the key-valuepair representing the setting associated with the second set ofsettings.
 6. The computer-implemented method of claim 1, furthercomprising determining to use the server-side hash value in a comparisonof the received client-side hash value and the server-side hash valuebased on the application identifier in the received communication. 7.The computer-implemented method of claim 1, wherein the server-side hashvalue was generated based on the modification.
 8. Thecomputer-implemented method of claim 1, wherein at least some of theconfiguration instructions correspond to a logging routine of theapplication.
 9. The computer-implemented method of claim 1, wherein oneor more settings of the second set of settings comprise attributes thatdefine whether or not the managed device is to apply the one or moresettings to the application.
 10. The computer-implemented method ofclaim 1, further comprising assigning attributes to one or more settingsof the second set of settings, wherein the attributes define whether ornot the managed device is to apply the one or more settings to theapplication.
 11. The computer-implemented method of claim 1, wherein oneor more settings of the second set of settings comprise attributes thatdefine that the managed device is not to apply the one or more settingsto the application.
 12. The computer-implemented method of claim 1,further comprising the managed device sending the communication as partof a startup routine of the application.
 13. The computer-implementedmethod of claim 1, wherein the second set of settings includes a settingthat disables or enables a routine of the application or includes asetting that changes a routine of the application.
 14. Thecomputer-implemented method of claim 1, wherein the second set ofsettings includes a setting that changes a level of detail for loggingin the application or includes a setting that disables or enables alogging routine of the application.
 15. The computer-implemented methodof claim 1, wherein the key-value pair is used by the application havingpreexisting code to identify how to apply a value of the key-value pairto the application based on a corresponding key of the key-value pair.16. The computer-implemented method of claim 1, wherein theconfiguration instructions for a setting of the second set of settingscomprises one or more variables for one or more functions of theapplication.
 17. The computer-implemented method of claim 1, furthercomprising the managed device sending the communication as part of aroutine of a software development kit (SDK).
 18. Thecomputer-implemented method of claim 1, wherein the second set ofsettings includes a setting that disables or enables at least one paidfeature, function, or routine of the application.
 19. A system forremotely managing settings of applications, the system comprising: oneor more data processors; and one or more computer-readable storage mediacontaining instructions which when executed on the one or more dataprocessors, cause the one or more processors to perform operationsincluding: receiving a communication from an application on a manageddevice, the received communication comprising an application identifierof the application and a client-side hash value of a first set ofsettings of the application; identifying a server-side hash value of asecond set of settings for the application using the applicationidentifier in response to the receiving of the communication, the secondset of settings comprising configuration instructions specific to theapplication identifier and were modified, prior to receiving thecommunication, in response to input provided via a device associatedwith the application to debug the application in association with thesecond set of settings, wherein the device is separate from the manageddevice; and based on a difference of the received client-side hash valueand the server-side hash value, transmitting, to the application on themanaged device, a key-value pair representing a setting associated withthe second set of settings to replace a first setting associated withthe first set of settings causing the application to apply theconfiguration instructions to modify a configuration of the application.20. One or more computer-storage media storing computer-useableinstructions that, when executed by a computing device, perform a methodfor remotely managing settings of applications, the method comprising:receiving a communication from an application on a managed device, thereceived communication comprising an application identifier of theapplication and a client-side hash value of a first set of settings ofthe application; identifying a server-side hash value of a second set ofsettings for the application using the application identifier inresponse to the receiving of the communication, the second set ofsettings comprising configuration instructions specific to theapplication identifier and were modified, prior to receiving thecommunication, in response to input provided via a device associatedwith the application debug the application in association with thesecond set of settings, wherein the device is separate from the manageddevice; and based on a difference of the received client-side hash valueand the server-side hash value, transmitting, to the application on themanaged device, a key-value pair representing a setting associated withthe second set of settings to replace a first setting associated withthe first set of settings causing the application to apply theconfiguration instructions to modify a configuration of the application.